Join Sheetal Elangovan and Robert MacDonald for an IBA Friday session. In this episode, they discuss 1Kosmos adaptive authentication.

Video Transcript
Rob:
Hi everybody, it's Rob and Sheetal. It's another IBA Friday. Sheetal, how are you doing today?

Sheetal:
Very well. How are you Rob?

Rob:
Doing good. We were just talking about going shopping this weekend, everybody. That's what that little banter was about and I was saying that I don't get invited anymore that because my daughters are a little bit older and they don't like taking me into stores with them. So I guess I'm at that age now. Are you at that age yet? Your kids are not at that age yet, right? Sheetal?

Sheetal:
Not yet Rob.

Rob:
Yeah, exactly. Yeah, exactly. All right, so on to bigger and better things. Today we're going to talk about authentication journeys, adaptive authentication, authentication orchestration. It's called many things, but when we think about authenticating a user, Sheetal, there's lots of things we probably should or we have to consider what their role is, what their permissions are, what their authenticating into. The methods we have available, where they're located potentially. There's all kinds of things that we have to consider when we're authenticating a user. And you've been working on a way to try to consolidate all of that into a, I don't want to call it a single UI or a single administrative experience to try to help admins provide or give admins a better experience in setting up those types of, again, journeys or orchestrations or whatever, whatever we want to call it, to authenticate users. Do you want to tell us a little bit about what you guys have been up to?

Sheetal:
Yes. So we've been in working with a lot of our customers, a lot of plain vanilla solutions, but you're just implementing MFA into the mix or you're going passwordless, but I think the biggest thing that customers care about is the continuous evaluation of risk. How much risk is associated with the login risk request that is happening right now? How can we sort of adapt to that risk that is presenting itself? And that's really what we've been working about, pushing the boundaries of every login. Anytime a user is there trying to log into a workforce application, we want to evaluate multiple signals that we're getting so we are able to make the right decision based on context. So let's quickly go into the slide that I have, Robert, because so much easier to explain with something.

Rob:
You built a slide?

Sheetal:
Yes, I know you don't like slides on IVA.

Rob:
No, I love slides.

Sheetal:
Who doesn't? Right?

Rob:
Exactly. Who doesn't love a good slide. But all kidding aside, this slide, this slide is a pretty good slide. I have seen this slide before.

Sheetal:
Okay, so with adaptive authentication, it's really about evaluating everything that's here on the left. Is this user who's presenting themselves to log in? Are they coming in from a high level of risk or a low level of risk? This determination can be done based on multiple factors. What is the device that they're logging in from? Are they coming in from a corporate domain? Are they coming in from an unknown device? What's the behavior? And I love this particular factor on behavior. Which type of the data are they trying to log in? Have they been at this IP address previously? That kind of information. Is it a new location? Have they traveled too much within a very short period of time? Because it's not possible that you're logging in from Canada.

Rob:
You're getting choppy on me. I think your internet is bad again. Are you there?

Rob:
You there? This is us. This is why we do these things live. Right Then it's fun. Something goes wrong. Sheetal, you still with me?

Sheetal:
Can you hear me?

Rob:
I can hear you. Why don't turn your video off and then maybe that might save some bandwidth.

Sheetal:
Okay, let's try that.

Rob:
We'll give the people viewing it this to look at only today. You still there?

Sheetal:
Yes, I'm still here.

Rob:
All right. We won't throw your internet provider under the bus like you and I chatted about yesterday, even though you're super, super close to their head office.

Sheetal:
Okay. Can you hear me better now, Rob?

Rob:
Yeah, you're very good now. Yeah.

Sheetal:
Okay. Okay, great. So it's basic evaluation as we were talking about. Of all things on the left, what is the application users trying to log in from? Is this request coming in from inside the network or outside the network? All of this great information as well as your geolocation. Once we have all of this information, it's very easy to sort of build a tailored journey based on the context. So at runtime we're evaluating all of this context and we're able to present all of these login options. One of the other things we've noticed, Rob, is that each customer comes in with a different kind of setting or a different kind of requirement. What is considered as the right kind of factor at one customer site may not necessarily be the same kind of factor that a user wants to be presented with at a different customer site.

And a good example of that would be that, hey, some customers really love hardware tokens. They want their users to authenticate with hardware tokens, especially if they're accessing hardware, high risk applications. So really we've seen a very different kind of factors needing to be presented depending on the customer. So we've made the entire experience extremely flexible where a customer can decide what does that context need to be and what kind of factors need to be presented at what time, right? Yeah.

So that's what we've done so far. And I think if you look at this site specifically, we can go into a different kind of authentication scheme. Very simple. You want to have something very plain vanilla, just multifactor authentication. We can support that. If you might not have something hybrid, and by hybrid we mean that an organization which is part going passwordless and has 2FA in the mix, then we are able to support that. Meaning we present different factors, customers are allowed to choose between all of them. And then if you are in a large organization and you have extremely complex environment, you can choose between a multiple set of options. So that's what we have here. You think we're ready to step into the demo, Rob?

Rob:
Yeah, I think that's a great idea. And again, some of the terms that you used there around adaptive and stuff like that, that can be intertwined with, what was the word I used earlier? Orchestration. So I think Gartner uses that term to describe some of these things that you're talking about as well. But just so everybody, we're all talking the same language. So you're going to show us now how this works, right?

Sheetal:
Yes.

Rob:
From an admin perspective, now what we're looking at is our AdminX portal, correct? This is where admins would go in and kind of set this stuff up.

Sheetal:
So what you're looking at here is our control plane. The administrator sort of goes in and they set up policies in here. As you can see here, this is representative of one of our customers where they have a specific policy for all of their administrators who are being logged in. And what's the factor they want to have, want to have something really simple, which is just a password. They want no two-factor authentication, but it's possible to do not the best,

Rob:
But it's not that you would want to do that, but if you wanted to just give your admins just password access, go for it. Yeah, I get it. Flexibility is yours.

Sheetal:
And then we have a customer here who has a FIDO user. So they're doing a rollout of FIDO tokens within their entire enterprise. So if you want to make sure that hey, I want to have certain applications within certain applications having a particular factor, then you're able to support that. And the setup was really easy. So you'll give your journey a name, you decide which application you want to have the policy apply to. You can choose from users, it can be as simple as just a username, or you can choose from groups. Like if you already have active Directory groups that you want to leverage, then you're going to use that and you can just keep layering multiple in here.

And then you go ahead and say, you know what? I want to make sure I want to have MFA in the mix. And you get to decide what kind of authentication methods you want to have. And I have block ID app codes, FIDO, push notifications. So these are all the different factors that we're going to present anytime I'm going to try and attempt to log into an application. So it gets presented really neatly nicely that this is the policy.

Let's move on. Save. Okay. This is another great example of a policy that we have here, and this is also live at one of our customers where if a user doesn't belong to a particular group, then we deny access. If they're not part of the Citrix groups, we want to make sure that no other user is able to log in. So deny access is an excellent use case. If you want users, you don't want to have access outside of a particular geolocation, or if they're not coming in from a known device, then go ahead, make sure you're denying access to those users. Very explicit, easy policy to minimize the risk from an organization perspective. And finally, the other one is around your network. Which set of IPs do you want users to come in from and how do you want to challenge them? So with this one, the business case is that if you're coming from outside...

Rob:
Did we lose you again?

Sheetal:
Did you lose me again?

Rob:
You said if you're coming from outside and then you went away,

Sheetal:
If you're coming from outside the network, then you have to be challenged with a higher form. Anything that is not secure, and we go ahead and present you with all the passwordless options.

Rob:
Awesome. So what you said there is that if you're coming from outside the network, you're going to be presented with a higher form of authentication. You broke up there just for two seconds, but I think that's where that was going, right?

Sheetal:
Yep. You filled the gaps pretty well.

Rob:
I can read your mind.

Sheetal:
Okay, so let's talk about what happens in the logging journey, right? So I'm going to go ahead, log out. Let's say a user's attempting to access, they put in their username. The minute they put in their username over here. What we're doing behind the scenes is we're submitting all of the factors that we have about this user's login, the IP, their behavior, the device that they're coming in from, multiple factors that are getting evaluated at this point of time. And then our risk engine turns up here and it gives you the decision that these are the factors the users will have to log in with and they present you with this screen.

Rob:
Now this is you, right? So you set now, did you not set this up earlier to have those three? Are those the three MFA methods that you had in that policy?

Sheetal:
Yes. So I've set it up to say that, hey, if I meet a certain set of IP conditions and I match certain groups, then these are the factors that I need to be challenged with. In which case, these are the factors that the risk engine returned and I will be able to log in with any one of these metrics.

Rob:
That's right. So it's not that you have to do all three of, you just have to pick which one you want to do.

Sheetal:
Yes, which one do you want to do?

Rob:
Got it.

Sheetal:
Okay. Okay. So that's our quick demo for the day and-

Rob:
Super cool stuff. I mean, legitimately though, I've worked for other organizations where they talk about being able to provide multifactor authentication, but really all they were providing is a 2FA because they could do username and password and something, but they couldn't do something else or provide something else was you had one option to stand as your MFA factor. The fact that you can say, Hey, they can choose any one of these, or if they come in to log into this, they have to use this factor. If they're part of this group and they're logging into something else, then they got to use a different factor is all pretty cool. And that could be all delivered through our platform. I think that's the other important thing to remember here too, is that we have all those capabilities built in. So it's not like you have to go out and buy other factors to make all of this come together. Our platform has those capabilities and you can use those in any way and at any point that you choose to, right?

Sheetal:
Yep. Yeah, it's a great means of threat mitigation, fraud prevention.

Rob:
That's cool stuff. All right, Sheetal, thank you very much everybody. That's our IBA Friday for today. Hopefully you got something out of that. If you want to learn more, you can always look up Sheetal and I. We'll be more than happy to tell you more about it. But at the end of the day, we do appreciate you coming along for the ride and we'll see you again next time. Thanks again. Have a good weekend, Sheetal.